perf(sequence): add From<Sequence<T>> for Vec<T> with Copy bound - #20

This is one of a set of 2 PRs that address issue number 2 described in ros2-rust/ros2_rust#628

This PR has to be merged before ros2-rust/rosidl_rust#26.

Problem

2. Element-by-element sequence conversion in from_rmw_message

The generated from_rmw_message code converts Sequence<T> to Vec<T> via .into_iter().collect(). The SequenceIterator::next() implementation (rosidl_runtime_rs/src/sequence.rs) does this per element:

let elem = ptr.read();
ptr.write(std::mem::zeroed::<T>());  // writes zero back for EVERY element

For a 64 KB Sequence<u8>, this is 65,536 individual read + zero-write + insert cycles instead of a single memcpy.

Solution

Adds impl<T: SequenceAlloc + Copy> From<Sequence<T>> for Vec<T> backed by seq.as_slice().to_vec(). For Copy element types (which covers all ROS 2 primitive types), this collapses to a single memcpy from the C-owned sequence buffer into a freshly-allocated Vec.

The companion PR in ros2-rust/rosidl_rust#26 updates the codegen template to call this impl on the receive side.

Microbenchmark

Using Criterion I ran a really quick benchmark between the before and after, just on the conversion from a Sequence<u8> of size 64K to a Vec<u8>. For my machine it gave the following numbers.

Speedup of .into() over into_iter().collect() at 64 KiB: ~45×.

The .into() form matches as_slice().to_vec() within ~1%, confirming the From impl inlines to the same code path.

End-to-end pub/sub throughput

I also ran an end-to-end benchmark where I compared rclrs before and after the change as well as an rclcpp baseline.

The benchmark ran in a single process with one publisher thread sending std_msgs/UInt8MultiArray messages and the main thread runs blocking executor.spin(). Reliable + keep_last(1000) QoS, default rmw_fastrtps_cpp. 5 s runs, median of 3.

Note that all the benchmarks below have quite a bit of run-to-run variance. The numbers are to show the trend and not an absolute comparison.

Node subscription (default API)

At 64 KiB this branch gives a 4.4× rclrs throughput improvement and brings rclrs to ~90% of rclcpp single-process parity. At 16 KiB it gives 1.27× and at 0 B - 1 KiB the change is near-noise because the conversion path is short, and small-payload Node throughput is dominated by per-message executor dispatch overhead, see Worker numbers below.

Worker subscription

The same bench with node.create_worker(()).create_subscription(...), which dispatches sync callbacks directly on the wait-set thread (no BoxFuture allocation, no mpsc hop):

With Worker subscriptions, rclrs on this branch exceeds rclcpp single-process Node at 64 KiB (224 k vs 151 k msg/s, ~1.48×). The two fixes compose: the conversion fix removes the per-publish memcpy ceiling, and the Worker path removes the per-receive dispatch ceiling.

Again note that there is quite a bit of run-to-run variance.

While performing those benchmarks I also ran into a fun issue with colcon-ros-cargo: colcon/colcon-ros-cargo#41